Castle main limitations.txt

   1 Interface proxy and properties only available on the implementation type\r
   2 ========================================================================\r
   3 \r
   4 Reported by: hammett (April 12th, 2006)\r
   5 \r
   6 This is easy to reproduce. \r
   7 \r
   8 public interface IMyService\r
   9 {\r
  10   void DoSomething();\r
  11 }\r
  12 \r
  13 [Transactional]\r
  14 public class MyServiceImplementation : IMyService\r
  15 {\r
  16   public int SomeParam\r
  17   { get and set implementation here }\r
  18 \r
  19   [Transaction]\r
  20   public void DoSomething()\r
  21   {\r
  22   }\r
  23 }\r
  24 \r
  25 And on the configuration\r
  26 \r
  27 <component \r
  28   id="my.service" \r
  29   service="IMyService, MyAssembly" \r
  30   type="MyServiceImplementation, MyAssembly">\r
  31 \r
  32   <parameters>\r
  33     <SomeParam>100</SomeParam>\r
  34   </parameters>\r
  35 \r
  36 </component>\r
  37 \r
  38 The Transactional/Transaction will force the container to create a proxy for the component. As the component was registered with a service contract (interface) dynamic proxy will generate an interface proxy. The container will try to set the propertu SomeParam on the proxy and boom, you have a nice exception.\r
  39 \r
  40 Possible solution: New version of DynamicProxy can make all proxies implement an interface ITargetAccessor. The container can check for this interface before trying to set anything on the component and voila!\r
  41 \r
  42 \r
  43 Transaction management: cannot suspend current transaction\r
  44 ==========================================================\r
  45 \r
  46 Reported by: hammett (April 12th, 2006)\r
  47 \r
  48 The transaction management that Castle is able to do is very limited compared to what DTC can offer (through COM+). In order to achieve the same level of features we would need to decide which path to take\r
  49 \r
  50 - Integrate with DTC\r
  51 \r
  52   Pros: fine-grained control of integration, support to 2PC, a possible lightweight way of handling transactions without involving COM+\r
  53   Cons: Few or non-existent documentation. MS really don't want developers 'messing' with their DTC otherwise they would have published its API documentation. It's Windows only.\r
  54 \r
  55 - Figure out a way of handling suspension or simulate a physical transaction suspension\r
  56 \r
  57   Pros: simpler solution\r
  58   Cons: might require lots of hacks\r
  59 \r
  60 - Integrate with COM+\r
  61 \r
  62   Pros: standard MS-way of dealing with transaction in an 'enterprise' fashion\r
  63   Cons: heavyweight, make deployments harder and more subject to 'strange' errors\r
  64 \r
  65 \r
  66 \r
  67 Windsor component proxies, when accessed through remote, methods are not intercepted\r
  68 ====================================================================================\r
  69 \r
  70 Reported by: hammett (April 12th, 2006)\r
  71 \r
  72 Windsor proxy factory choses between two approaches to generate proxies:\r
  73 \r
  74 - If the type extends MarshalByRef it uses the standard .net infrastructure to construct a proxy\r
  75 - If the type does not extends MarshalByRef it uses DynamicProxy\r
  76 \r
  77 However there's an issue with .net proxies, when used in a remote context the calls are not intercepted. A possible solution would be to register a custom sink on the transportation channel being used. There's no easy way of doing this non-intrusively, so it would be up to the user to add a custom sink through the configuration file that configures the remoting infrastructure. The sink, though, need to be coded.\r
  78 \r
  79 \r
  80 \r
  81 Dynamic proxies cannot be used in a remoting context\r
  82 ====================================================\r
  83 \r
  84 Reported by: hammett (April 12th, 2006)\r
  85 \r
  86 Is there a way to transient types cross boundaries?\r
  87 \r